The "Wayland.Fyi" Stack

2026-05-20

As I wrote about here, not too long ago I moved from the BSPWM window manager to SOWM. I had not even considered making the jump from x to wayland, primarily because the options available as regards wayland compositors were to put it plainly, shit. I appreciate that a wayland compositor has to do a lot more than a wm in x by virtue of x itself being massively bloated and doing all of that work itself, but still, even the supposedly "minimal" options such as sway are just far too heavy and complex for me. I was never one of those people who looked down on wayland for some perceived architectural flaw, rather, I looked down on wayland for the lack of options. Which makes sense, given that it is harder to write good software for wayland since your software has to do more. When I look at the way people use hyprland it just disgusts me. I could never use one of these garbage desktops with all the animations and transparency. I don't ever want these "features" anywhere near me. When I open a terminal I want the terminal to fucking open, not play an animation while I wait. Ricing is supposed to enhance your usage of the computer, not get in the way of it. Anyway, I had basically looked at all the available wlroots wayland compositors available and decided to keep waiting until something actually good comes along.

So something actually good came along. It calls itself swc. Or neuswc. Or wayland.fyi. Or the dérive linux desktop stack. Or "suckless wayland". It goes by many names. You can read about it on wayland.fi, but to summarise: it's based on this project called swc, forked into neuswc, which is "a small Wayland compositor implemented as a library." Compared to wlroots, it's just infinitely simpler, if you want to make a window manager you only need to implement two callback functions, newwindow and newscreen, which get called when a new window or screen is created. Then you can focus on making your window manager actually, you know, manage windows. Because the neuswc library makes it so easy, there are already a wide array of options for wms built on this stack available despite the project being very young. Well, the original swc by Michael Forney is like a decade old, but the fork which renewed interest in this idea is as far as I can tell only really a few months old. So after discovering this, I set my sites on making the jump. Of course, it's never that easy.

The first time I had tried this, I had been using freeway, which just didn't work. As it says in the readme: "it's not reccomended sic] for general day-to-day desktop use." Basically it didn't work. I came back a few days later and tried again with regular libwayland. I had some issues getting stuff to compile, but I don't remember the details and I managed to get it worked out relatively easily. What really cased me problems was what happened next. After getting everything to compile and launch, I booted into [tohu. I had chosen tohu because it seemed very similar to sowm, which I was previously using, and it is also considered the "reference implemenation for neuswc", so I assumed it would work well. I could get tohu to launch, but I could not launch any programs from it. It's the sort of wm where you need keybinds to launch a terminal or a dmenu type program. It wasn't doing that. What was going on? I spent I believe 8 or 9 hours stuck on this problem, which is frankly embarrassing because the solution was so obvious I should have figured it out much faster. But anyway, was it not registering keyboard input at all? Was it registering the input but not executing the programs? Was it a problem in tohu or in swc? Was it something else entirely? You don't understand how long this took me to figure out. I even at one point went into the IRC to try and ask for help, but got nervous and left. I'm not proud to admit I did resort to asking claude for help, but even with it's assistance it took so fucking long to narrow down the bug.

So what was it in the end? The keybindings all use the "super" key (mod4), and swc's XKB ruleset is hardcoded as "base", which did not know that the super key exists. To fix this I had to go into seat-evdev.c in neuswc and change the line:

seat->names.rules = "base";

to

seat->names.rules = "evdev";

That was it. Literally one word. Recompiled and everything worked. I should probably submit a patch about this.

Well I have now been using this stack for a few days, I actually switched from tohu to neuwm because it has various features that I like, but I think at some point I will probably end up writing my own tohu/wsxwm fork.

This project is mostly getting attention because of Hevel, a window manager where the desktop is an infinte 2 dimensional, scrollable, zoomable plane of floating windows, making heavy use of plan9 inspired mouse chording. It's a very cool project, but I am on a laptop and mouse chording just requires finger gymnastics which are geometrically unpleasant.

I am not going to lie to you, this shit does crash from time to time. It used to crash more, particularly when interacting with text boxes on firefox, because of something to do with neuswc not having a proper text input protocol or some such shit, because all of this is half finished. To be honest I don't really understand it, but running firefox via xwayland has circumvented the problem mostly. It still crashes sometimes and I'm not sure why, but it's infrequent enough that I can deal with it. "Why would you put yourself in a position where you have to learn to live with crashes in the first place when more stable alternatives exist and are in wide use rather than this autistic larp?" I have no good answer to that question.